This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
Traditionally, information and telecommunications services have been offered based on the use of monolithic servers. Such a kind of servers comprise processing logic and data storage capabilities that allow them to process the signaling they can receive, as well as the signaling to be sent, by using data they store internally.
However, factors such as, among others: scalability, performance or deployment/implementation cost, are starting to drive towards another kind of solution, wherein the functionality provided by some monolithic servers is -say-“tiered” resulting into a layered architecture. In brief, the principle behind this kind of solution consists on decoupling the service logic processing from the mere data storage.
A layered architecture comprises, in essence: a plurality of signaling front-ends FEs and a back-end database server system DBS. In short, the FEs comprise the necessary signaling and processing means for providing the specific service(s) they serve, while the DBS merely stores the data that can be needed by a FE for processing a service. Depending on factors, such as: the amount of data to be stored, access availability, data distribution policies, etc; the DBS can comprise one or more database nodes DB (e.g. each comprising one machine, or a cluster of machines), wherein, also depending on implementation factors, some data can be replicated in more than one DB.
For example, in a telecommunications system, servers which are being envisaged so as to be adapted according to a layered architecture are, among others: Home Location Registers HLR, Home Subscriber Servers HSS, Device Configuration Registers DCR, Service Policy Controllers SPC (e.g. such as PCRFs, as described in 3GPP specification 23.203 V8.2.0, Jun-2008), Authorization and Authentication servers AAA. These kind of servers, in monolithic implementations, use to hold and store internally data related to a plurality of users, some of which can be common regardless the application/service type served by a specific server, and, therefore, can benefit from a layered architecture implementation, wherein some/all of the user data related to these applications are stored in a common DBS.
In these kinds of layered scenarios, FEs of a telecommunications system (e.g. HLR-FEs, HSS-FEs, DCR-FEs, etc.) can then become (standard) database clients of a database server DBS, which makes possible to use commercially available database solutions rather than devising costly proprietary products. For example, some DBSs available today offer high-performance storage and reliability features, and allow using well-known standardized access protocols, such as the “Lightweight Directory Access Protocol” LDAP, for providing access to many kinds of eventual database clients.
A further advantage of a layered architecture is that the signaling load from service clients of a given service, for example clients of the services provided by a HLR or HSSs (such as e.g.: Mobile Switching Centers/Visitor Location Registers MSC/VLRs, Serving GPRS Support Nodes SGSNs, Call Session Control Functions CSCFs, etc), can be distributed along the plurality of available HLR and/or HSS FEs acting, on the one side, as if they were monolithic HLR/HSS servers for the service clients and, on the other hand, as database clients for the DBS. Therefore, the service availability is increased, since the signaling load due to these clients can be distributed along a plurality of available FEs, which can be selected by using any suitable distribution algorithm. Besides, these FEs can be implemented by -say- “light-weight” machines that do not require a high data storage capacity. Also, operation and maintenance O&M tasks over the necessary user data is simplified, as only the DBS is to be contacted and not a plurality of servers, which also helps to keep data consistency when the same user data is used for more than one application/service.
In summary, as the Telecom networks grow more and more complex, providing an increasing variety of services, the need of a common centralized database for a diversity of applications is more and more evident. In this way services can be introduced in less time and data management becomes simpler, reducing operational expenses (OPEX) and capital expenditures (CAPEX.).
This centralized Telecom database should have at least the following characteristics:                Resiliency, high availability        High performance—low latency        High capacity        Scalability        Geographical redundancy        Flexible deployment        Single point of access (one in each geographical location)        No single point of failure        
Many companies are offering Telecom databases with these characteristics
A geographically distributed database provides geographical redundancy, being resilient when disasters occur. But it obliges the clients (such as front-ends of: Home Location Register (HLR), Home Subscriber Servers (HSS), Authentication Center (AuC), etc) to be aware of the data distribution and the status of the database in each location. Therefore, the clients need to be configured individually so as to know in which location the data they need resides, and not only that. It has to know where the copies of the different data are Located.
Issues relating to data distribution and replication along a plurality of database nodes have already been addressed. In this respect, several prior-art documents are cited herein: U.S. Pat. No. 6,539,381 B1 (hereinafter referred as document D1), document “Adaptable Replica Consistency Service for Data Grids” (Ruay Shiung et A1; Information Technology: New Generations, 2006. Third International Conference on Las Vegas, April 2006, NV, USA 10-12 Apr. 2006. IEEE. PISCATAWAY, N.J., USA, 10 Apr. 2006, pages 646-651. ISBN 978-0-7695-2497-9; hereinafter referred as document D2), or document “Understanding Replication in Databases and Distributed Systems” (Distributed Computing Systems, 2000. Proceedings. 20Th International Conference on Taipei. Taiwan 10-13 Apr. 2000, Los Alamitos, Calif., USA. IEEE Comput. Soc, US, 10 Apr. 2000, pages 464-474, ISBN: 978-0-7695-0601-2; hereinafter referred as document D3).
Document D1 discloses a solution for synchronizing the status of data replicas that are distributed along a plurality of database nodes, and to update their contents. According to D1 each database node of the plurality stores information (called “state vectors”) with regard to the updating status of every data replica distributed along every other database node, as perceived by a particular node. The “state vectors” of D1 comprise “time stamps” indicating when a particular data replica has been updated on a database node, as perceived by a particular node (e.g. D1: column 9 lines 47-50; column 10 line 43-column 11 line 21; column 12 lines 36-58; FIGS. 4, 5A, 5B, 5C and 5D). According to D1, the database nodes exchange “state vector” information upon change on a data replica on any of them (e.g. D1: column 12 line 36-column 13 line 26). According to D1, a database/network administrator determines which database node holds the master replica (e.g. D1: column 2 lines 8-18; column 9 lines 42-60; column 10 lines 43-48).
Document D2 also addresses data consistency problems when certain data are replicated along a plurality of database nodes of a “data grid” infrastructure comprising database nodes storing a “master” replica of certain replicated data, and database nodes storing read-only (called “secondary”) copies of these replicated data, wherein data modifications are made only over master replicas, and wherein modifications are subsequently made on the secondary copy or copies (e.g. D2: Abstract, chapters 1 and 2). In particular, D2 discloses a solution based on a “multi-master” concept, wherein the database nodes of the data grid are divided into “regions” comprising database nodes closely located, wherein each “region” holds one master replica for certain replicated data, and wherein a locking mechanism is used to allow consistency among database nodes when certain replicated data are modified in a database node holding a “master” copy (e.g. D2: chapter 3.2). More precisely, D2 discloses a mechanism for keeping data consistency among nodes holding “master” data replicas in different “regions” upon modification of certain (replicated) data in one of them, wherein said mechanism is based on exchanging between database servers on different regions of “time-stamp” information (referenced therein as “sequence number”) indicating at what time a particular master data replica has been updated on a database node (e.g. D2: chapter 3.3). When coming to designating a node hosting a “master replica” for certain replicated data. D2 refers implicitly a manual configuration method as in D1 (e.g. D2: chapter 2 paragraph 2), or explicitly a method based on system loading and network bandwidth (e.g. D2: page 4 left hand column, paragraph 1, lines 16-18).
Document D3 also addresses issues relating to data distribution and replication along a plurality of database nodes, and also discloses a solution wherein data modifications are first made on the database node holding the “master” copy of the concerned data and, then, subsequently replicated to the database node(s) holding copies of said data (e.g. D3: chapter 4.3). Document D3 does not however add any teaching to determine a database node, among a plurality, hosting a “master replica” for certain replicated data.
In summary, the problem of deciding consistently and in a distributed and automated manner which database node host the master replica for a certain data is not addressed in an efficient manner by the prior art.